For nearly forty years, the Basic Input/Output System (BIOS) has been a standard type of firmware used to perform hardware initialization during the booting process (power-on startup) on personal computers (PCs). BIOS also provides run-time services for an operating system and programs after booting of the operating system. The fundamental purposes of the BIOS in PCs are to initialize and test the system hardware components, and to load a boot loader and subsequently an operating system from a mass memory device or network storage. The BIOS additionally provides an abstraction layer for the hardware until drivers are loaded. As such, variations in the system hardware are hidden by the BIOS from programs that use BIOS services instead of directly accessing the hardware.
Unified Extensible Firmware Interface (UEFI) has been developed as a successor to BIOS, aiming to address technical shortcomings of BIOS. Today, new PC hardware predominantly ships with UEFI. UEFI is applicable across a wide range of devices (servers, workstations, etc.) and central processing units (CPUs) (x64, ARM64, etc.). UEFI defines two types of services: boot services and run-time services. Boot services are available while the UEFI firmware owns the platform, and boot services include text and graphical console services on various devices, and bus, block and file services. UEFI has a resident portion—run-time services—which remain accessible while the operating system is running. Run-time services include services such as date, time, and non-volatile random access memory (NVRAM) access.
UEFI operates in 1:1 mapping mode, wherein virtual addresses are identically mapped to physical addresses. Operating system (OS) kernels typically use low virtual address spaces, typically the lowest 4 GB (to be compatible with legacy BIOS firmware), but low virtual addresses are frequently part of the user address space. As a result, run-time services needs to be re-mapped carefully to an unused portion of the kernel virtual address space.
Unfortunately, many UEFI firmware implementations have one or more limitations, because they may not fully comply with the UEFI specification. For example, many implementations of the firmware require both the new and the old mappings to the kernel virtual address space to exist during the run-time service re-mapping operation. In addition, although it would be preferable to map all time run-time services in the kernel virtual address space so as to consume the least amount of the virtual address space, some firmware implementations force relative offsets between run-time services memory regions to be maintained.